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i DUPLICATE 

Mobile Security 

A number of solutions exist for hosts to remain mobile while moving across different 
access networks (such as UMTS or WLAN). These solutions are based on the idea of 
allowing traffic flows to be redirected into the current location of the mobile node. In 
one solution, Mobile IPv6, the traffic flows are identified by a stable IPv6 address. In 
another solution, HIP, a public key (or a hash of a public key) identifies the traffic 
flows. In either case, a stable forwarding agent is required somewhere in Ihe network for 
other nodes to contact the mobile node without previous knowledge of the current 
location of the mobile node. 

In Mobile IPv6, this stable forwarding agent is called the home agent, and a security 
association must exist between the home agent and the mobile node for unauthorised 
location updates to be prevented. In HEP, there is no need for such a security association 
as the public key can be directly used to identify a particular node in a secure maimer. 
However, in order for other nodes to learn the public key of the HEP-based mobile node, 
this public key must be stored in DNS in a secure manner. Therefore, in both cases the 
mobile node must be capable of securely performing transactions to its "home 
network", either for the purpose of talking to its home agent or updating the DNS to 
store its public key at the deployment phase. 

Typically, the set-up of the security association for the home agent or the update of the 
DNS is performed in manual fashion. While parts of these operations have been 
automated, for instance through the use of a public key infrastructure, the authorisation 
step has to date remained a manual operation. In Mobile IPv6, this step involves the 
decision of whether the particular mobile node (even with a certificate from a trusted 
third party) is allowed to use a particular IPv6 address. This step is not easy to automate 
through public key infrastructure, given that the infrastructure would typically be unable 
to tell which IP address assignments are made in the network. In HIP, this is easier but 
requires the existence of a public key infrastructure and that it has made a determination 
7* of ^whether the mdbile node is allowed to control the given domain name. The existence 
of such a public key infrastructure can be seen as redundant and unnecessary, given that 
the purpose of the DNS system is to act as a public key infrastructure - it would be 
strange to require another public key infrastructure to enter data into DNS. 
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^The above technical problems lead to a service deployment problem in future networks. 
It is unacceptable from a business perspective to require manual work in order to set up 
each and every mobile node (out of millions) for the mobility service. Instead, it is 
preferred that the existing security mechanisms can be used to bootstrap whatever 
security may be required by the mobility mechanisms. 

According to the present invention there is provided a method of securely initializing 
subscriber and security data in a mobile routing system when the subscribers are also 
subscribers of a cellular radio communication network, the method comprising: 

within the mobile routing system, authenticating subscribers to the mobile 
routing system using an authentication procedure defined for the cellular radio 
communication network, collecting subscriber information from relevant nodes of the 
cellular radio network, and agreeing upon keys by which further communications 
between the subscribers and the mobile routing system can take place; and 

using said subscriber information and keys in the provision of mobility services 
to subscriber mobile nodes and correspondent nodes. 

According to a second aspect of the present invention there is provided a method of securely 
initializing subscriber and security data in a mobile routing system (such as Mobile IP) 
when the subscribers are also subscribers of a cellular radio communication network, 
the method comprising: 

I. authenticating subscribers to the mobile routing system using the cellular radio 
communication network authentication, 

II. collecting subscriber information related to the cellular radio communication 
subscriber from the relevant nodes of the cellular radio network, 

m. agreeing upon a key or keys by which further communications between the 
subscriber and the mobile routing system can take place, 

IV. communicating said subscriber information and keys to the mobile routing system, 

V. using said subscriber information and keys in the offering of the mobility service to 
the mobile node and its correspondent nodes. 
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.Step I may use underlying auth vs. rerun SIM authentication. For step HI the keys may 
either be MIpv6 shared secrets between the MN and the HA, or HIP public keys which 
will be stored in DNS and used by the MN, forwarding agent and even peers. 

For step I, the subscriber info can be a name or phone number which can be translated 
to a FQDN under the operator's domain. Then you can connect to, e.g. jsmith.sonera.fi. 
Then no administrator is needed at the operator site or the mobile node to set anything 
special up for this. 

A subscriber database may be used, in the context of the so called subscriber 
certificates, to construct a FQDN which would be put in as an attribute of the produced 
certificate. 

Cellular devices marketed by vendors typically contain a slot for a SIM card. The SIM 
cards are distributed by the operators, and they are used to authenticate the device to the 
network so that it can, for instance, make phone calls. Network operators have 
authentication servers which can verify the authenticity of the requests sent to it, and 
subscriber databases which contain phone number, name, and other information 
associated with a particular SIM card. 

Our solution is to use the SIM card authentication, authentication servers, and 
subscriber databases to bootstrap the required security associations and DNS entries. 
The solution consists of the following steps: 

Step 1. The client device establishes (DP) network connectivity by establishing a 
connection through GPRS, for instance. This step may involve the use of the SIM (or 
USIM) card for network access authentication; we consider the network access 
authentication to be an independent process, even if it uses the same SIM card as we use 
for another purpose. (But see later where we present a variation which can rely on 
network access authentication only.) 

Step 2. The client device communicates with an authentication server in the operator's 
network to execute the SIM (or USIM) authentication with the server: 

- The device sends its identity to the server. 

- The server sends a challenge to the device. 

- The device optionally verifies the authenticity of the server's challenge. 



XN-ij-A jut **tyj** 



k - The device sends a response to the server. 

- The server verifies the authenticity of the device's response. 

- The server optionally sends an acknowledgement back to the device. 

- Bom the device and the server establish shared session key(s), such as the USIM CK 
and IK. 

Step 3. The client generates a public key pair. 

Step 4. The client sends a message to the server, protected using the shared session 
key(s) established in Step 2. The message contains the following information: 

- The public key of the device 

. - An optional signature of the device, made using the private key associated with the 

public key 

- Optional desired parameters, such as a desired fully qualified domain name 
(FQDN). 

- Optional shared secret (if provided, this part must be encrypted). 

Step 5. The server verifies the authenticity of the client's message through the use of the 
shared session key(s) and optionally through the signature. 

Step 6. The server collects information from the subscriber data base and the current 
contents of the local DNS zone and a Mobile IPv6 home agent or a HIP forwarding 
agent This information may consist of, for instance, 

- The name and postal address of the user associated with this SIM card. 

- The telephone number associated with this SIM card. 

- The existing FQDNs in the DNS (either for tins particular subscriber or for others). 

- The status of any mobility services established earlier for the particular subscriber or 
SIM card. 

Step 7. The server makes a decision about a suitable FQDN and/or IP address which can 
be assigned to the device. For instance, the server can check the desired FQDN for 
consistency with the operator's domain name (e.g. sonera.net), the user's phone number 
or name (e.g., matti-virtanen.sonem.net), and the existence of possible previous entities 
with the same FQDN. The server also makes the necessary configurations in the 
following entities: 

• The local DNS zone: the selected FQDN and the associated public key is stored there. If 
HIP is used, the address of the operator's HIP forwarding agent is stored mere as well. 

- The operator's Mobile IPv6 home agent or HEP forwarding agent 

- The subscriber data base (possibly including a change in the billing information) . 
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.Step 8. The server communicates the configuration back to the device: 

- The chosen FQDN and, optionally, IP address 

- Optionally, the public key of some network node used by the device (such as a 
home agent) 

Step 9. The node stores the received information. Note that this information has to be 
handled in a special way if a separation exists between a device and the user's 
credentials such as is common in phones and SIM cards inserted to them. Leaving the 
information in the device for use by any user (SIM card) would allow the use of this 
information by other users. This risk can be mitigated by storing the received 
information in the SIM, or storing it in the device in a manner which isn't accessible 
after another SIM has been inserted 

As a result, the device can now use mobility services in a secure manner: its public key 
and the forwarding agent can be retrieved from the DNS by anyone from the Internet 
and communications can flow to the device regardless of its current position and IP 
address. If a Mobile IPv6 home agent is used, the communications between the home 
agent and the device can be secured using the public key and/or shared secret 

Step 7 can be seen as the DNS name ownership test, and is in principle similar to the 
issues related to address ownership in IP mobility. 

Current state of the art allows manual configuration as discussed earlier. This is 
unacceptable in the given business environment 

There exists proposals that make use of cell phone authentication in other contexts (e.g. 
RFC 3310), so the reuse of SIM authentication itself is not new. Here, however, we use 
it in a specific way for a specific application and combine information from the 
subscriber data base as well. 

There exists proposals that make use of cell phone authentication even in the context o£ 
e.g., Mobile Ipv6. However, these proposals use such authentication every time, and 
lack a mechanism to decide the IP addresses and FQDNs. 
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^^There also exists proposals to use cell phone and other legacy authentication 
^^mechanisms to generate so called subscriber certificates in general fashion, suitable for 
any application. However, our solution above avoids this step, and avoids the use of any 
PKI other than the resulting DNS system as a (weak form of) aPKI. Also, it is not clear 
that these general solutions can make the necessary authorisation decisions regarding 
FQDNs and IP addresses. 

Standard protocols exist for making dynamic updates to DNS. However, currently these 
are secured with pre-provisioned shared secrets (DNS TSIG) or other mechanisms 
which can provide a shared secret, such as Kerberos (GSS TSIG) or secure DNS. All of 
these mechanisms today make the security decisions without regard to the specific 
entity that is making the request This is insufficient, as it is necessary for a specific 
node to control its own IP address and DNS name, but not the addresses and names of 
other nodes. Our invention deals with this by combining the user data base and the 
authentication. 

Embodiments of the invention would enable an easier deployment of mobility in 
heterogeneous networks. 

A question which may need to be addressed is what happens if a device moves to a 
WLAN network. The same procedure can be applied if the cellular network is still 
available and if WLAN and cellular access are under the control of the same operator. If 
there are different, operators than the whole procedure should include negotiations 
between authentication servers of those operators. 

Two different cases should be considered. 

(a) Reuse of access-level authentication as such. 

(b) Run another authentication between the mobility servers and the mobile node, but 
use the same credentials (e.g. SIM) as we did for the access. 

The above concern may be relevant to case a. For case b, this is not an issue because 
whatever happens at lower layers is not relevant For case a, a solution is to allow two 
different networks to use the same authentication, negotiate the authentication type, 
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transform information around (This is happening as a part of IETF AAA and BAP 
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^protocols, and through 3GPP's work on 3G-WLAn interwoddng.) 
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